1. Technical Field
The present invention relates generally to processing signed Java applets in a Java runtime environment.
2. Description of the Related Art
Java™, originally developed by Sun Microsystems, is a known software programming environment in which software programs, known as Java applets or applications, are developed, tested and maintained. Java programs have found extensive use on the World Wide Web, which is the Internet's multimedia information retrieval system.
About a year ago, Sun's JavaSoft introduced the Java 2 development platform. The Java 2 Java runtime environment (JRE) includes a Plug-in that allows developers and users to run applets in their web browsers with different JREs. The ability to specify other JREs allows developers to call Java 2 methods within their applets. Applets running with the Java Plug-in can create Java 2 security objects and call their related methods. One common use of these methods is to request a permission for an applet, such as permission to access a file or thread resources, that ordinarily is not granted to the applet.
It is often desirable to sign an applet so that a user can verify that the applet is supplied from a trusted source. Currently, there are at least three different prevalently used methods for distributing a signed Java applet over the Internet: Java Development Kit (JDK), Netscape, and Internet Explorer. These methods, however, differ from each other in several ways. JDK uses a JDK-signed “jar” file to distribute the signed applet, which can be executed in a browser based on the JDK security model. The algorithm used to verify the signature in the applet is DSA/SHA1, and the certificate database used to verify signers of the applet is keystore and/or cacerts. JDK is the policy used to honor the signers of the applet when determining permissions. Netscape uses a Netscape-signed jar file to distribute the signed applet, which can only be executed by Netscape Communicator. The algorithm used to verify the signature in the Netscape-signed applet is RSA/MD5, and the certificate database used to verify. signers of the applet is cert7.db or a certificate server. The policy used to honor signers of the applet when determining permissions is Netscape-specific. The Microsoft Internet Explorer method uses a signed “cab” file to distribute the signed applet, which can only be executed by Internet Explorer. The algorithm used to verify signatures in the applet is RSA/MD5, and the certificate database used to verify signers is Microsoft system store or user store. The policy used to honor the signers of the applet when determining permissions is Internet Explorer-specific.
Because of these differences, the various distribution methods are incompatible. For example, the signatures of an applet that was signed using the Netscape method cannot be verified and honored by Internet Explorer. Similarly, the signatures of an applet that was signed using the Internet Explorer method cannot be verified and honored by Netscape Communicator. Therefore, if an applet developer wants to distribute a signed applet to all three browser types (Netscape Communicator, Internet Explorer, and JDK-based browsers), the developer must go through the inconvenience of packaging the applet in three different ways and supporting three different types of certificate database and security policy configurations. FIGS. 1A-1C illustrate the three ways of packaging applets that exists in the prior art due to these incompatibilities.
The Java Plug-in module, which is provided with the Java Runtime Environment (JRE), provides one limited solution to this problem. This solution allows developers to distribute applets signed using the JDK method to Netscape Communicator and Internet Explorer, as well as to JDK-based browsers. FIG. 2 illustrates the solution offered by the Java Plug-in method. While this approach has some advantages, the Java Plug-in solution supports only the JDK method. This method is unsatisfactory to developers and users on the Netscape Communicator and Internet Explorer platforms, which are far more popular.
One problem with the JDK method is that it is less secure than the Netscape Communicator and Internet Explorer methods. In particular, the DSA/SHA1 algorithm that is used by JDK to produce signatures is weaker than the RSA/MD5 algorithm that is used to produce signatures by Netscape and Internet Explorer. Also, the JDK method does not check whether any of the certificates in a subject's certificate chain have expired. Another problem with the JDK method is that does not support the Netscape and Internet Explorer certificate and key databases. Therefore, before a developer on the Netscape or Internet Explorer platform can sign an applet using the JDK method, the developer must configure a JDK certificate and key database. Also, before a Netscape or Internet Explorer user can verify the signatures in applets that were signed using the JDK method, the user must configure a JDK certificate database. Yet another problem with the JDK method is that it does not support dynamic verification of signers based on the signer's certificate chain to a trusted certificate authority, as does Netscape and Internet Explorer. Using the JDK method, a user must configure the signer in-the certificate database before a user can download an applet signed by that signer.
As one of ordinary skill in the art will appreciate, the Java Plug-in solution has several problems when used with signed applets. The major problem is that the only kind of signed applets supported by the Java Plug-in solution are JavaSoft signed applets. Thus, the many Netscape-and Internet Explorer-signed applets either cannot be verified or are not supported. The JavaSoft method of verifying signed applets is less secure and flexible than the methods used by Netscape and Internet Explorer, mainly because of the weaker and less flexible verification algorithms and procedures used by the JavaSoft JDK.
The present invention addresses these and other deficiencies of the prior art.